This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b322220:

@Christian24 Interestingly we'll need to apply a workaround both on Jsdom and the browser to handle delegatesFocus. Invoking shadowHost.focus() does not delegate the focus in nested shadow trees while the mousedown which we will use this for does delegate through multiple shadow hosts to the first focusable in the browser.

This entire conversation has caused me into looking into focus handling in Shadow DOM in a different light. It is a mess. It seems to work oddly differently everywhere. How do you want to get this consistent? Also do you want to apply the workarounds to the library's tests or in user land? How do you see chances of jsdom implementing delegatesFocus?

A bit of context maybe as well: We use delegatesFocus mostly to get an application that can be easily navigated by tab.

This entire conversation has caused me into looking into focus handling in Shadow DOM in a different light. It is a mess. It seems to work oddly differently everywhere.

That isn't exclusive to this feature. When you work on this library, you get to know a few quirks of browsers and frameworks you might not expect. ;)

How do you want to get this consistent? Also do you want to apply the workarounds to the library's tests or in user land?

It looks as if the behavior in the browser regarding the user interaction is consistent - according to MDN:

The delegatesFocus read-only property of the ShadowRoot interface returns true if the shadow root delegates focus, and false otherwise.
If true, when a non-focusable part of the shadow DOM is clicked, the first focusable part is given focus, and the shadow host is given any available :focus styling.

On delegatesFocus: true we need to find the focusable element and apply focus there so that the click behavior matches the behavior in the browser.
I think it makes sense to handle delegatesFocus: undefined as true. Users who want a different behavior in Jsdom will need to set the property themselves.

How do you see chances of jsdom implementing delegatesFocus?

I filed an issue. But even if it's implemented, I don't think it is relevant enough to be backported. So most users would still use versions without it.

A bit of context maybe as well: We use delegatesFocus mostly to get an application that can be easily navigated by tab.

How keyboard navigation handles shadow trees needs to be researched, but there might be no special handling, so our tab order helper would just need to consider all focusable elements no matter if they are in a shadow tree.

Codecov Report

Merging #1038 (b322220) into main (1aa2027) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main     #1038   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           88        87    -1     
  Lines         2061      2091   +30     
  Branches       691       711   +20     
=========================================
+ Hits          2061      2091   +30     

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Looks good now.

Changes on top of the other PR:
https://github.com/testing-library/user-event/pull/1038/files/cbe1391f14f8319ec737e48b3878caad80c6f3a5..HEAD